Network Working Group M. Speer 
Request for Comment: 2029 D. Hoffman 
Category: Standards Track Sun Microsystems, Inc. 

October 1996 


RTP Payload Format of Sun’s CellB Video Encoding 
Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 

Official Protocol Standards" (STD 1) for the standardization state 

and status of this protocol. Distribution of this memo is unlimited. 
Abstract 


This memo describes a packetization scheme for the CellB video 
encoding. The scheme proposed allows applications to transport CellB 
video flows over protocols used by RTP. This document is meant for 
implementors of video applications that want to use RTP and Cell1B. 


1. Introduction 


The Cell image compression algorithm is a variable bit-rate video 
coding scheme. It provides "high" quality, low bit-rate image 
compression at low computational cost. The bytestream that is 
produced by the Cell encoder consists of instructional codes and 
information about the compressed image. 


For futher information on Cell compression technology, refer to [1]. 
Currently, there are two versions of the Cell compression technology: 
CellA and CellB. CellA is primarily designed for the encoding of 
stored video intended for local display, and will not be discussed in 
this memo. 


CellB, derived from CellA, has been optimized for network-based video 
applications. It is computationally symmetric in both encode and 
decode. CellB utilizes a fixed colormap and vector quantization 
techniques in the YUV color space to achieve compression. 
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2. Network Packetization and Encapsulation 
2.1 RTP Usage 


The RIP timestamp is in units of 90KHz. The same timestamp value is 
used for all packet payloads of a frame. The RTP maker bit denotes 
the end of a frame. 


2.2 CellB Header 


The packetization of the CellB bytestream is designed to make the 
resulting packet stream robust to packet loss. To achieve this goal, 
an additional header is added to each RTP packet to uniquely identify 
the location of the first cell of the packet within the current 
frame. In addition, the width and height of the frame in pixels is 
carried in each CellB packet header. Although the size can only 
change between frames, it is carried in every packet to simplify the 
packet encoding. 


0 1 2 3 
Ori 2I AS ET 0 h 2 354 5 ET Os 2 3 A GeT Or Ae 2354 567 
-+-+-+-+-+-+-+-+-+-+ +H HHH 
Cell X Location | Cell Y Location 
-+-+-+-+-+-+-+-+-+- +H HMHH 
Width of Image | Height of Image 
FStStStetatetStatetatatatatatatatatStatatatatatatatatatatatatet 
Compressed CellB Data | 


FStStStStetaStStatetStaetatatStaetatatatatatatetatatatetatetatatst 


+——+—+—+ 


All fields are 16-bit unsigned integers in network byte order, and 
are placed at the beginning of the payload for each RTP packet. The 
Cell X and the Cell Y Location coordinates are expressed as cell 
coordinates, not pixel coordinates. Since cells represent 4x4 blocks 
of pixels, the X or Y dimension of the cell coordinates range in 
value from 0 through 1/4 of the of the same dimension in pixel 
coordinates. 


2.3 Packetization Rules 
A packet can be of any size chosen by the implementor, up to a full 
frame. All multi-byte codes must be completely contained within a 


packet. In general, the implementor should avoid packet sizes that 
result in fragmentation by the network. 
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Appendix A - Structure of the CellB Video Stream 


The CellB bytestream consists of cell codes, skip codes and 
quantization-table specific codes. These are now described. 


A.1 CellB Cell Code 


Cell codes are 4 bytes in length, and describe a 4x4 pixel cell. 
There are two possible luminance (Y) levels for each cell, but only 


one pair of chrominance (UV) values. The CellB cell code is shown 
below: 
0 1 2 3 


Ord 2-3. 415: 65 J 89 OE 2 34 SO E DOL 2 3846. BOs ONL 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
J[oOoMMMMMMMMMMMMMMMUvUvUvUvVv|yyyyyyyYYyY]| 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

4x4 Bitmask U/V Code Y/Y Code 


The first two bytes of the cell code are a bitmask. Each bit in the 
mask represents a pixel in a 16-pixel cell. Bit 0 represents the 
value of the upper right-hand pixel of the cell, and subsequent bits 
represent the pixels in row-major order. If a pixel’s bit is set in 
the 4x4 Bitmask, then the pixel will be rendered with the pixel value 
<Y (1), U, V>. If the pixel’s bit is not set in the bitmask, then the 
pixel’s value will be rendered with the value <Y(0), U, V>. The 
bitmask for the cell is normalized so that the most significant bit 
is always 0 (i.e., corresponding to <Y(0), U, V>). 


The U/V field of the cell code represents the chrominance component. 
This code is in index into a table of vectors that represents two 
independent components of chrominance. 


The Y/Y field of the cell code represents two luminance values (Y(0) 
and Y(1)). This code is an index into a table of two-compoment 


luminance vectors. 


The derivation of the U/V and Y/Y tables is outside the scope of this 
memo. A complete discussion can be found in [1]. 
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A.2 CellB Skip Code 


The single byte CellB skip code tells the CellB decoder to skip the 
next S+1 cells in the current video frame being decoded. The maximum 
number of cells that can be skipped is 32. The format of the skip 
code is shown below. 


0 1.2-3 a 
+-+-+-+-+-+-+-+-+ 
|joosssss| 
+-+-+-+-+-+-+-+-+ 


A.3 CellB Y/Y Table Code 


The single byte "new Y/Y table" code is used to tell the decoder that 
the next 512 bytes are a new Y/Y quantization table. The code and 
the representation of the table are shown below. The sample 
encoder/decoder pair in this document do not implement this feature 
of the CellB compression. However, future CellB codecs may implement 
this feature. 


01234567 
+-+-+-+-+-+-+-+-+ 
|11111110] 
+-+-+-+-+-+-+-+-+ 


The format of the new Y/Y table is: 


0 1 2 3 

(ils ie a= eas a ce Os nee ier ok ee Oe eas ae OO 0 a OR a 
tata ta tata tata ta tata tata ta ta tata ta tata tata ta ta tata tata ta ta tatatat 
| Y1_000 | Y2_000 |. ¥izo01 |- -v2 001 | 
+-+-+-+-+-+-+-+-+-++tH HHHH 


0 1 2 3 
01234567012345 670123456701234567 
t—+-+-4+-+-4+-4+-4+-4+-4+-4-4+-4+-4-4-4+-4t-4-4-4t-4+-4-4t-4+-4-4-4+-4t-4-4+-4-4+-4 
| Y1_254 | Y2_254 Vo Y12255 l 1 “¥2=255 | 
t—+—-+-4+-+-4+-4+-4+-4+-4+-4-4+-4+-4-4-4+-4t-4-4-4t-4+-4-4t-4+-4-4-4+-4t-4+-4+-4-4-4 
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A.4 CellB U/V Table Code 


The single byte "new U/V table" code is used to tell the decoder that 
the next 512 bytes represent a new U/V quantization table. The code 
is shown below. The sample encoder/decoder pair provided in this 
document do not implement this feature of the CellB compression. 
However, future CellB codecs may implement this feature. 


01234567 
+-+-+-+-+-+-+-+-+ 
S e baa 2] 
+-+-+-+-+-+-+-+-+ 


The bytes of the new U/V quantization table are arranged as: 


0 1 2 3 
Ol 28 a See OL 2: Baa Se Ord 23 aS ie OAL 2 Ae 5 6 
t—+4+-+-4+-+-4+-4+-4+-4+-4+-4-4+-4+-4-4-4+-4t-4-4-4t-4+-4-4-4+-4-4-4+-4t-4-4+-4-4-4+ 
| U_000 | v_000 |  U_001 |  v_001 | 
tata ta tata ta tate tata ta tata tata ta ta tata ta tata tata ta tata tata tatatat 


0 1 2 3 

01234567012345 670123456701234567 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H+H 
| U_254 | V_254 |;  U255 | 2255 | 
t—t—+—-4+-+-+4+-4+-+-4+-4+-t-4+-t-t-4 ttt t tata t tata titi ti tat itat tat 


Appendix B - Availability of CellB 


It is the viewpoint of Sun Microsystems, Inc, that CellB is 
publically available for use without any license. 
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